Modern database system architectures may have dozens, if not hundreds, of databases that serve multiple hundreds to thousands of business transactions per second and hundreds of thousands of data selection requests. Such systems generally suffer from exhaustion of computation resources, poor response times and lack of availability that in a very short time can endanger database continuity to underlying business functions.
A current way of addressing such issues is to use a database monitoring system that performs periodic real time data sampling of database performance statistics (for example, in case of an Oracle RDBMS these may include system statistics, wait events, latches, etc.). In some cases, formulas based on database performance statistic values are calculated and used (such as ratios, etc.).
Monitoring may be performed on one or more databases. The following three monitoring system architectures are common:                1) Database monitoring system that consists of a monitoring console to read performance sampling data directly from one or more databases (single-tier architecture);        2) Database monitoring system that consists of monitoring consoles and monitoring agents, where performance sampling data is read by monitoring agents that are deployed to every monitored database, and monitoring consoles communicate with monitoring agents to read necessary information (two-tier client-server architecture);        3) Database monitoring system that consists of monitoring consoles, monitoring server and monitoring agents, where performance sampling data is read by monitoring agents that are deployed to every monitored database, and where the monitoring server communicates with monitoring agents to read collected information and provides information input to monitoring consoles (three-tier architecture).        
Database performance statistics data are analyzed by a monitoring system to identify critical conditions that endanger a database's availability to business requests. Upon identification of critical conditions, notifications are sent to interested users.
While monitoring systems described above are well known in the art, major issues arise, such as:                1) With a large number of databases to be monitored simultaneously, visual analysis of many monitoring panels is prone to errors and inefficient;        2) In many cases database problem identification based on a value of a database performance statistic reaching preset absolute thresholds is not early enough to provide a database administrator (DBA) enough time to successfully drill-down and resolve the issue;        3) Database problem identification based on a value of a database performance statistic reaching preset absolute thresholds can provide false signals, due to the changing nature of underlying business (an old absolute threshold can be too low or too high to represent accurately current database activity);        4) Many database monitoring agents may need to be deployed, maintained and reconfigured on a constant basis, and manual elements of the process are very time consuming and error prone;        5) Database performance can be impacted by negative performance of other databases (such as read-write replication clusters or functionally similar/dependent databases, databases sharing same storage, etc.), and such identification of indirect dependencies needs to be made in a short time frame to prevent negative impact on database performance.        
As a result, use of existing database monitoring systems in the rapidly growing database environment is becoming unscalable.
It would, therefore, be desirable for a database monitoring architecture to be able to maintain an ability to provide early proactive identification of critical issues across multiple databases and an ability to provide a consolidate view of critical issues across multiple databases, as well as to maintain mass deployment, reconfiguration and maintenance of database monitoring agents.